C/C++ Users Group Library 1996 July

home *** CD-ROM | disk | FTP | other *** search

/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 177_01 / shell.doc < prev next >

Wrap

Text File | 1986-01-02 | 43.6 KB | 1,251 lines

-- DR. SHAW'S DOS SHELL -- User's Reference Manual 01/01/86 Introduction and Overview: This document is meant to serve as a reference guide and tutorial for the use of the Shell. It will be updated whenever any of the planned quarterly modifications are actually implemented in the Shell. If you want to get directly to "The Right Stuff" in this Manual and learn how to start or use the Shell, skip to the sections "How to Start the Shell" and "How to Use the Shell". Otherwise, read on. Acknowledgements: There are a number of people without whose support, criticism and ideas the Shell would not have been possible. It would be impossible to name all of them here since some of them are people whose works I have read or whose programs I have used, and provided influences in strictly an inferential and indirect manner. I would, however, like to acknowledge those whose suggestions and ideas, whether they realized it or not had the most profound influence on the Shell's development: Bob Leder Chuck Sites Christine Groat Leor Zolman Rick Rump Elliot McGuire Timothy Landgrave Felix Kagi Mark DeSmet Joel Farley Dedication: To my friend, mentor and colleague, Bob Leder, whose many suggestions I happily implemented, and who faithfully beta-tested quite a number of early versions of the Shell, this User's Reference Manual is dedicated. 1 Philosophy and History: Every major program has its own Philosophy, or set of principles upon which it stands. The quality of a program is usually determined by how thoroughly those principles have been defined and how effectively they were then implemented. The current Shell is the end result of two programs: the original idea, first attempted in late 1984, and the present result. The original idea was not very well defined. I had grown used to Rick Rump's Microshell product for CP/M systems, and when I moved to MS-DOS/PC-DOS, I found the DOS command-line interpreter just as lacking as the original CP/M CCP, upon which it was based. The best capabilities I found in the DOS command- line interpreter were those drawn from counterparts on UNIX systems. I decided to try to write a simple command-line interpreter that would allow you to issue more than one command on the command-line. I did NOT envision then writing a complete interface to the operating system. As a result, the earliest incarnation of the Shell was little more than a parser that allowed multiple commands on the command-line, separated by semi- colons. It was originally written with the Mark Williams' MWC86 C compiler in December 1984, and did NOT even allow proper use of conventional DOS commands like DIR. It was only good for running programs, occasionally. The next revision, the first really usable one, was given birth around early February, 1985, and featured usage of all DOS commands, with the Shell first checking to see if what you typed was a DOS command, and failing that, attempting to execute it as a .COM, .EXE, or .BAT file respective (which is how DOS does it). It also allowed review and re-use of the last 20 command-lines thanks to Bob Leder, who added this touch one cold Saturday in February, while I took his son sledding in Cherokee Park. Written with Mark DeSmet's C compiler (which I still use), it was with this version that I actually began to use the Shell in its own development. There were over the next 6 months a number of revisions that included the UNIX-like commands, cp and ls, for copying files and viewing directories, respectively. Also, a number (in fact, as far as I know nearly all) of the prominent bugs were fixed, including one that would mysteriously crash the Shell after a few minutes, or hours usage. I slowly found them, the one bad one teaching me to hesitate to use someone's not-so-well-debugged public domain windows package (or any other kind of code, I subsequently wrote my own). The next major breakthrough, though, was when I stripped cp, ls and several other commands out of the Shell and made them external as opposed to internal commands. Not only did it make the Shell more memory efficient (it still only uses 32-48k), but I was able to incorporate the alias feature that gives any user of the Shell the opportunity to implement his or her own commands, with the same priority that DOS gives to its own commands, and to even rename commands. This subsequently led to the office-menu capability and the sprucing up of cp and ls, not to mention the inclusion of several new commands. I look forward to other programmers in particular 2 developing new commands for the Shell, and hope that they will pass these back to me for redistribution so that we can all benefit from them. ------------------- The whole idea behind the Shell was to make DOS easier to use, not harder! At the same time, I felt that offering a strict menu-driven or icon-driven (like the Macintosh or 1-Dir) interface, discouraged the advanced, "Power - User" (a la PC Magazine). The Power-User is used to getting a lot done at one time, and usually knows the next two or three commands he's going to issue in advance. Therefore, the "single-step", "do this - stop - then do this" approach of Menu- or Icon- driven interfaces often becomes cumbersome and unproductive. Since it would be nice to issue a whole series of commands to DOS, all at one time, that was the first feature of the Shell to be implemented and becomes the most obvious, immediate advantage to the new Shell user. The Shell, like DOS veriosn 2.00 and above, was written with the hard-disk user in mind; this doesn't mean it won't work on a floppy disk system, but just like DOS it runs infinitely better on a hard disk system. With the price of hard disks what they are (internal 20 meg under $ 700), I venture to say that the 2- floppy-only system will become a thing of the past in a year. I've tried to create an expandable ENVIRONMENT in the Shell, to fit the needs every user of DOS. The Shell doesn't get in the way (unless you have only 64K!), but instead enhances DOS. I would like to see it enhanced further, and would like to release quarterly revisions, whenever feasable (not unforseeable, as I seem to generate some kind of improvement every couple of weeks). Anyway, I hope you like the Shell and find it as useful as I have. I hope you'll give me some constructive feedback after you've used it. TradeMark Acknowlegements: Listed below are the trademarks and their respective owners for products referred to in this Manual: Trademarks / Owner: Microshell / New Generation Systems CP/M / Digital Research MS-DOS / MicroSoft PC-DOS / IBM UNIX / AT&T Bell Laboratories MWC86 / Mark Williams Company DeSmet C / C Ware SideKick / Borland International dBASE III / Ashton-Tate IBM-PC / IBM Compaq / Compaq Computer WordStar / MicroPro International 3 A Word on Payware(tm), and User's obligations: You'll see my Payware notice when you first bring up the Shell. Like other user-distributed software, your obligation only comes if you decide you want to use the Shell. I suggest you try it, and it you like what it does, use it. Then, send me the $ 25.00. If you don't use it, don't send me anything. I don't expect you to pay for software that is not productive to you. You can, however, give a copy of it to anyone you wish. Just don't alter or remove the boot message (after all, you can go around it, I tell you how in this manual). I will offer paid users upgrades to future versions at minimal or no cost, depending on the feasibility of the distribution and the value of the upgrade. I do expect some nice new features to be added by the end of the first quarter, 1986. Hardware, Software and Memory Requirements The Shell is designed to run on the IBM-PC, Compaq, or close ROM-BIOS compatibles. It requires MS-DOS or PC-DOS version 2.0 or above. It uses a maximum of 48k of memory (verified by executing the MEM command, loading another Shell on top of the first, executing MEM again, and subtracting the difference in available memory from the two MEM commands). 4 How to Start the Shell: There are only a few steps to starting the Shell. If you get an archived, squeezed or library version off of one of the Electronic Bulletin Boards, you will need to unsqueeze it. Some of the Bulletin Board versions provide .BAT files for installing the Shell, so you may need only to run the appropriate .BAT file to install everything. Once this has been done, you will need to have the actual Shell program file, SH.EXE in your current directory or in a directory on the path (if you are not familiar with the DOS PATH command, ask a cohort - barring this call me - barring that, last but not least, read the DOS manual). It is also helpful to have the file CONFIG.SH in the same place as SH.EXE, but not essential. If you don't you'll get a warning message, but you can go on. I would suggest, though, that you study the file CONFIG.SH (you can use your favorite word processor or text editor) and become acquainted with its contents, because it is a key to your being able to tailor the Shell and its commands to your needs and it will be a focal point of future Shell development. I cover this in more detail in the section "How to Use the Shell". Anyway, if you don't have CONFIG.SH on your path or in the current directory when you boot the Shell, put the Shell's utilities (cp, ls, ...) in a directory on the path. BUT, to get the maximum efficiency out of the Shell, put the utilities in their own directory, and make sure that the lines in CONFIG.SH give a complete path to the directory you put the utilities in. For example, if you put the utilities in a sub-directory of the root directory, called say, \SHBIN, then the line in CONFIG.SH for a utility like cp might be: cp=c:\shbin\cp.exe This becomes even more interesting if you use a RAM disk. Load all of the utilities into RAM (probably drive D) and the line would read: cp=d:\cp.exe or maybe cp=d:\shbin\cp.exe if you have any sub-directories on the RAM disk. Whatever you do, just make sure that each utility listed with a full path to where it is located if you are going to use the CONFIG.SH file. Then just boot it up: A>sh or C>sh If you must get out of the Shell at anytime (most of the time, you WON'T have to), just type EXIT and you'll be back at good old (somewhat boring) DOS. Before Bringing Up the Shell: 1. Set up any environment variables (PATH, etc.). (Future versions will allow these to be changed from the Shell itself.) 2. Load any RAM-resident utilities. 5 How to Use the Shell: Multiple Commands on the Command-Line First off, the Shell you can execute as many commands as you can fit on width of the screen. For instance, instead of: C>dir . C>dir b: . C>ws . C>erase *.bak . C>cd\payroll . C>do payroll . C>cd\finances . C>lotus you can do the same with: dir;dir b:;ws;del *.bak;cd\payroll;do payroll;cd\finances;lotus all you have to do is substitute a semi-colon on the command-line everywhere you would ordinarily type a Carriage- Return. Editing the Command-Line Made a mistake typing in that line? Editing is easy. Use the following wordprocessing control keys to make changes to the command line (the ^ represents the Ctrl key): To move the cursor: left: <- or ^S right: ^D or -> word left: ^A or ^<- word right: ^F or ^-> To edit the command line: delete character: ^G clear field to right of cursor: - ^T Backspace delete - Del Insert mode on/off - Ins or ^V Review and/or Re-edit the Command-Line Or if you'd like to re-use and/or edit the previous 19 command lines, just browse through them with the up/down arrow keys (or ^E and ^X), and press RETURN to run the selected line. This makes repetitive tasks and mistakes easy to correct. 6 Commmands The Shell supports most of the standard internal DOS commands directly and in many instances has been observed to perform them even faster than PC-DOS. Among those supported directly are: CLS, DEL/ERASE, REN/RENAME, RMDIR/RD, CHDIR/CD, and MKDIR/MD. Also, two additional commands have been added: MEM - shows total installed memory and total memory free. RM - like erase or del. Other internal DOS commands such as: COPY, DIR, DATE, TIME, VER, VOL, <, >, and | are supported but use DOS to perform them. Many of these have counterparts among the Shell's own set of external commands, and these counterparts are often faster, more productive and more useful than the DOS originals. Of course, the big advantage is that you (or your programmer friends) can add your own commands to the Shell, in a virtually unlimited fashion. The Shell is distributed with a set of external commands that more than take the place of the original DOS versions. Among these are: LS - for Listing fileS and directories MV - for renaming and/or moving a file to a different disk location. TYPE (or CAT) - for typing files CP - for CoPying files UNIQ - for removing duplicate lines of a sorted file. CHMOD - for changing attributes of files to be: read-only, hidden, system, or archival. TEE - for splitting the output of a pipe or filter to both the screen and wherever else you want. These are described in detail on the following pages. 7 LS is a directory listing command, that is far more informative and useful than DIR. For instance, here is the output of LS with the -l option for the directory I am writing this manual in: d---- 0 Sep 09 10:09a 1985 [..] d---- 0 Sep 09 10:09a 1985 [.] d---- 0 Dec 13 01:24p 1985 [y] ----a 1152 Sep 09 10:10a 1985 autobio ----a 0 Jan 03 00:14a 1986 file ----a 12288 Oct 18 09:09a 1985 leor ----a 8832 Oct 22 08:20p 1985 leor2 ----a 384 Oct 24 11:14a 1985 plauger ----a 7680 Dec 14 09:06p 1985 shell.doc ----a 2304 Dec 11 06:26p 1985 shell ----a 21632 Jan 03 00:04a 1986 shhelp.bak ----a 21760 Jan 03 00:14a 1986 shhelp.txt ----a 768 Sep 26 00:19a 1985 super.tl ----a 317 Dec 13 10:04a 1985 x ----a 122 Dec 13 01:25p 1985 z # files: 15 # bytes: 77239 (90112) Remaining space: 3860480 The items on the left are file attributes, which show that the first three files are directories (also obvious because LS puts directory names in [ ]), and the remaining files can all be archived by DOS's BACKUP. Each entry shows the file size in bytes, the date and time of the last update along with the file name. The default order is always alphabetical with the directories 1st. The "# bytes" is the space taken by the files. The figure in parenthesis is the real space taken up on the disk (helpful since the hard disk files always use space to the next 8k on DOS 2 and the next 2k on DOS 3; and floppy files use space to the next 4k). The remaining space is just that. To use LS: ls -fil *.dbf *.dif x*.com where "-fil" is an example of the options for LS and the rest are files with or without wildcards. Yes, you CAN give ls more than one filename at a time (the "Remaining Space" figure is based on the drive implied by the first directory/file-spec in a list). As to the options which can be combined considerably: -f: files (non-directories) only -i: fast video, should not be used in redirection, but for fast video output only (programmers: the 'i' is for int 10h) -l: long format listing (like above, otherwise you get filenames only) -t: sort by date/time of last update -r: reverse the selected sort order -s: single column (name only) listing -d: directories only listing -c: columnar format -p: show a page at a time (beats using the MORE filter!) -?: message that shows how to use ls and the options 8 Since the Shell lets you make up and create your own commands (listed in CONFIG.SH), a number of versions of ls have been created without any effort at all and are referenced in the CONFIG.SH file distributed with the Shell. Each one becomes it's own independent command and does NOT require any programming or expertise: l - like ls, but with filenames only. (ls -li) lc - like l, but in columns. (ls -ci) lr - l sorted in reverse time of update order (ls -lrit) (shows most recently updated files last) LS is based on the UNIX command of the same name, but some of the more creative ideas in it came from Mike Ouye's version with DeSmet C, with tasty suggestions from Chuck Sites and Bob Leder. ------------------------- MV is another useful Shell command, that is primarily used to MoVe a file from one directory to another, without having to copy it. What MV does, is rewrite the directory entries associated with a file, instead of making a copy of it elsewhere on the disk. This saves the step of have to delete the original copy of the file, and is much faster. It can also be used to rename a file when a full pathname is involved. The present version does NOT support wildcards. To use it: mv \oldpath\filename \newpath\filename which would move "filename" from the directory "oldpath" to the directory "newpath". ------------------------- The TYPE command in DOS has 3 counterparts in the Shell: TYPE - just like the original, only faster. TYP - just like TYPE with the MORE filter in use, in other words TYPing a file will only put up one screenful at a time until you press a key to continue. CAT - for the UNIX afficiandos, the same as TYPE. all of which are found in CONFIG.SH file as variations on the CAT command. With all three of these you can specify a sequence of files to be printed on the screen: type file1 file2....filen TYPE does not accept wildcards. 9 CP is an external Shell command that not only lets you copy one file to another file, but also allows you to copy an entire list of files or directories at once. You can specify which files in a group you do NOT want to copy, or you can give names of directories whose files you want copied, and CP will expand the directory-name to include every file immediately accesable in that directory. To just copy one file to another: cp file1 file2 which will copy FILE1 to FILE2. To copy more than one file in a list requires an understanding of what I call the "last item" rule. The "last item" rule in using CP is that the "last item" in the list MUST be the destination, that is, where you are copying the files to. For instance if you want to copy the files: AUTOBIO, LEOR, SHELL in the directory listing above to a directory called \PAYROLL: cp autobio leor shell \payroll The only time the "last item" rule is relaxed is when you copy a single file specification to the current directory. Like if you wanted to copy a file called EMPLOYEE.DAT from \PAYROLL to the current directory, in which case the "last item" is implied to be the current directory: cp \payroll\employee.dat or if you wanted all of the .DAT files in \PAYROLL to the current directory: cp \payroll\*.dat Now you might think that to get ALL of the files in the \PAYROLL directory, you would use: cp \payroll\*.* which would work, but cp will expand a directory name by itself to directory\*.*, so that cp \payroll will do the same thing! This means that if you want to copy all of the files listed in the first example above, and all of the files in the sub- directory Y (but not including its own sub-directories) to \PAYROLL: cp autobio leor shell y \payroll 10 In fact, you could even copy the files in directories called \A, \B, and \C to a subdirectory of \PAYROLL called \D: cp \a \b \c \payroll\d (remember the "last item rule": the last item is the destination to be copied to). If the destination you are copying files to is the current directory and you have more than one file in the list use '.' or ".\" to specify the current directory. For instance, to copy the files in \A, \B, and \C to the current directory: cp \a \b \c . or cp \a \b \c .\ CP supports the use of wildcards ("*.*", "*" and "???") and lets you specify which files should NOT be copied. Suppose you want to copy all of the S*.TXT and L*.* files in the current directory (listed by LS above) to a directory called ..\LTRS, but you do NOT want to copy the file called LEOR2: cp s*.txt l*.* !leor2 ..\ltrs which says: "copy the s*.txt and l*.* files but NOT a file called leor2 to a directory called ..\ltrs". While it's copying CP will respond with: copying shhelp.txt to ..\ltrs\shhelp.txt...completed copying leor to ..\ltrs\leor...completed Notice that the "leor2" file (from the directory listing above) was not copied. Again, the "!" says do NOT include this in the list even though you said "l*.*". One big advantage to using CP in addition to being able to get a whole bunch of files copied at once is that CP will use as much memory as you have available on the machine for copying. It will often read into memory an entire file (even 300-400k files!) before writing the copy out to the disk, which means that copying with CP can be extraordinarily fast! Although its roots are found in the UNIX utility, cp, the spirit of the current program can be found in the version that Leor Zolman distributes with BDS-C. 11 UNIQ is a filter that removes duplicate lines of a sorted file, and should be used like MORE with pipes or redirection. For instance, in a batch file called MAKDIRS.BAT that Bob Leder wrote: cd \ tree | find "Path: " | repl "Path: " "md " | sort | uniq > %1 In this example, the output of the DOS TREE command is piped to FIND, which looks for the phrase "Path: " and tells REPL (a filter that replaces every occurance of one phrase in a file with another) to replace every "Path: " with "md ", then calls SORT to sort the file, and UNIQ to strip out any duplicate lines. The end result is written to a file that you specify when you run MAKDIRS, for instance: C>MAKDIRS dirs.bat and DIRS.BAT will now be capable of reproducing the entire directory structure of your hard disk on another hard disk. That's a long winded example of how to use UNIQ (and four billion other things). ------------------------- CHMOD is a command that is used to change a file's attributes (the same one's shown on the left in the LS listing above). With CHMOD you can set a file to be read-only (you can't write over it), system or hidden (not found in standard directory searches), or archival (able to be archived by DOS). To use it: chmod [+ | -] [rhsa] [filename] where a '+' means turn on the attribute, and '-' means to turn an attribute off. The "rhsa" are the various file attribute combinations (r - read-only, h - hidden, s - system, a - archival), and "filename" is the name of the file whose attributes you want to modify. As to a couple of simple examples, suppose you wanted (as I like to do) to make your copy of COMMAND.COM on your hard disk read-only, so you won't accidently erase it, or copy over the wrong version (I would hate to smother it with a DOS 1.0 version!). You do this with: chmod +r command.com or perhaps you have a floppy disk formatted with the /s (system) option, and you want to free up the space used by the hidden files: ibmbio.com and ibmdos.com (which you can see listed by LS): chmod -rhs a:ibmbio.com chmod -rhs a:ibmdos.com CHMOD does not accept wildcards. 12 TEE is a program that is used in pipes to display on the screen what is passing through the pipe. In the example above, the batch file MAKDIRS.BAT, we can use TEE to display what is passing through the pipe without interrupting the output of the pipe itself: tree | find "Path: " | repl "Path: " "md " | sort | uniq | tee %1 TEE is best used at the end of the pipe, as we have done here. It will send a copy of the input to screen and another copy to the file specified after it. In this case the file is the one substituted by the variable %1. ------------------------- Other DOS Commands Before bringing up the Shell, you should have setup the following DOS commands as you will want them to be: BREAK, PATH, PROMPT, VERIFY, and SET. The key to remember here is that the Shell is NOT a RAM-resident program like SideKick. It is actually an application-program that interfaces with DOS to make it easier to use. This means it is easy to get out of should you need to, and cannot be accused of being incompatible with any RAM-resident programs you might be using (plus this makes it less buggy and easier for me to maintain). Prompts Currently the default prompt gives a full path to the present working directory. Support for the conventional DOS configurable prompt should be present in a future version. 13 Menu-Generation The Shell has some simple menu-generation capabilities for use in a office or automated enviroment. This means that you can customize a machine to the point where both computer illiterates (who might want Menus) and Power-Users (who will typically like the Shell environment) can co-exist on the same machine. Menu outlines are kept in a file that is specified in CONFIG.SH by an entry like: menu=c:\menudir\menu.cfg where "menu" is a key-word in CONFIG.SH, and in this example, MENU.CFG is a menu configuration file found in the directory called \MENUDIR. This is also the directory where the menu-associated batch files are kept (for more information on CONFIG.SH, see section "Adding Your Own Shell Commands"). To generate a menu, modify the menu configuration file (I'll call it MENU.CFG in the examples here) to include a menu command and a description for each item you want displayed on the menu. The key is to have one command and description on each line in MENU.CFG, in the form of command=descriptive phrase, where the "command" is really the name of a batch file and therefore no more than 8 characters. To generate a set of menu items like: Payroll Run Payroll System GL Run General Ledger you would have the lines: Payroll=Run Payroll System GL=Run General Ledger in MENU.CFG. Any line that does NOT have the '=' sign in it will be centered and printed literally. To put a title on the menu, enter the title line in MENU.CFG in the exact order it will be displayed on the screen and: Shaw*American Technologies Office System blank Payroll=Run Payroll System GL=Run General Ledger would generate a menu like: Shaw*American Technologies Office System Payroll Run Payroll System GL Run General Ledger Notice that the word "blank" as the first phrase on a line means put a blank line on the screen. For every entry in MENU.CFG with an '=' sign, you will need to have a .BAT file that changes to that directory of your system, and boots or loads the appropriate program. If the Payroll entry above really ran a dBASE III system, then you will 14 need a batch file called PAYROLL.BAT that might have the following in it: echo off cd\payroll dbase payroll cd\ Make sure that you place all menu related .BAT files in the directory designated by the "menu=pathname" entry in CONFIG.SH as I mentioned above. To enable the menuing capabilities, bring up the Shell with the -m option and the command "menu" (this can be done with AUTOEXEC.BAT: sh -m menu The -m option enables menuing and tells the Shell to look for a "menu=" entry in CONFIG.SH. If it is found, the Shell will read the configuration file to generate a menu. The menu will not be initially displayed until a "menu" command is issued to the Shell, although that can be done when the Shell is brought up (as shown above). You may choose to issue a "menu" command later on. Issuing a "menu" command when the Shell was NOT brought up with the -m option will NOT generate a Shell menu. The Shell will automatically give precedence to a menu command over other commands, and will always re-display the menu upon exiting the .BAT file for that command. Also, a Shell menu will always be redisplayed by entering the command "menu". Try it, we use it in our office all the time! Issuing Start-up Commands: As shown above, the Shell will accept arguments on boot in the following form: sh -m cp \shbin\*.exe d:;menu This example from my AUTOEXEC.BAT file will boot the Shell with menu capabilities enabled, copy all of the .EXE files in \shbin to drive d, and show the menu. Another example might boot the Shell, change to a directory called \UTIL (where utilities are kept), and show all of the *.EXE files there: sh cd\util;lc *.exe 15 Adding Your Own Shell Commands (featuring CONFIG.SH): Probably one of the Shell's most powerful features is its ability to reference commands by different names, and allow the user (you!) to specify what a command should mean! In other words, you can add your own commands to the Shell, which is something DOS will NOT really let you do (barring the use of .BAT files). When the Shell is first brought up, it looks for a file called CONFIG.SH in the present working directory (pwd) or on the environment path. If the file is found, the Shell will read it and from it initialize a set of internal commands and their translation into real executable programs. Like the menu configuration file, the statements in CONFIG.SH shoulbe be in the form: command=execution_string -options arguments where "command" is the command you want to be able to use, the "execution_string" is the full path and filename of a program to be executed, "-options" are any additional options to be passed, always beginning with '-', and "arguments" are any additional parameters to be given. For instance to get the output of LS every time you type DIR, just enter the following line in CONFIG.SH: dir=c:\shbin\ls.exe where anytime you type DIR as a command, it will instead run the LS program found in \SHBIN. You can do this with virtually any command. You can also add your own as you write (or find) other programs you would like to have as part of the Shell's environment. There is also a speed advantage, as the Shell will load and execute it's own set of commands via CONFIG.SH, faster than it will others. If you make a change to CONFIG.SH, you will need to exit the Shell (just type "exit") and restart it for the new CONFIG.SH to take effect. The next revision of the Shell will probably have a command to re-initialize the commands from CONFIG.SH, without having to leave the Shell. Two keywords are reserved to have special meaning to CONFIG.SH and should NOT be used for commands: MENU=gives the path and name of the menu configuration file and the path to the associated menu .BAT files. LOG=gives the path to a directory where .LOG files will be kept (see the section "Generating Logs of Shell Usage"). 16 The following is my current CONFIG.SH: menu=c:\shbin\config.shm log=c:\shbin\logs cp=d:\cp.exe ls=d:\ls.exe -i lc=d:\ls.exe -ci l=d:\ls.exe -li e=d:\e.exe cat=d:\cat.exe -i typ=d:\cat.exe -pi type=d:\cat.exe -i dir=d:\ls.exe -i uniq=d:\uniq.exe chmod=d:\chmod.exe diff=c:\bin\diff.exe lr=d:\ls.exe -lrit mv=d:\mv.exe To Quit the Shell If at any time you want to get out of the Shell, just enter the command "exit". This will return you to good old (yawn) DOS. 17 Generating Logs of Shell (and therefore Computer) Usage The Shell has the capability of maintaining a daily log of computer usage. When the log-file option is enabled, every command-line that you execute in the Shell will be written to the log-file. One log-file is generated for every day the Shell is used (provided the DOS system date has been properly set). Multiple sessions on a given day are recorded sequentially in the same log-file with a time-stamp showing the beginning of a new session. A typical log (like this one named "12-12-85.log") file might look like this: 23:25:09 l -d \shbin\*.* l \shbin\logs\*.* exit 23:29:20 cd\shbin\log cd\shbin\logs l cat 12-12-85.log time ws ws ws exit 23:32:08 ws ws exit The times stamped into the log show that I started the Shell on three different occasions (just before midnight). The Shell automatically uses the system date to name log files, and because the system date was set to 12-12-85, the log file was named "12- 12-85.log" Log file capabilities are enabled in the Shell by starting the Shell with the -l option. For instance to start the Shell with the log-file enabled: sh -l or to start it with both log-files and menus enabled: sh -lm etc. The log files are always kept in the directory specified by the appropriate entry in CONFIG.SH: log=c:\shbin\logs in which case the log files will be kept in a subdirectory of \shbin called (appropriately) "logs". 18 The End (for now). (This page intentionally left almost blank.) 19